Reimplements the feature proposed in #134 by @LEggcookies for the current federated / universal_ble architecture. The original patch targeted the pre-federation native Android/iOS sources, which no longer exist — credit for the idea is theirs.

What

MidiDevice.serviceUUIDs exposes the service UUIDs a BLE peripheral advertised, so an app can narrow discovery beyond the MIDI service filter to specific hardware:

const vendorService = '0000fe59-0000-1000-8000-00805f9b34fb';
final devices = await midi.devices ?? const <MidiDevice>[];
final vendorDevices = devices.where((d) => d.serviceUUIDs.contains(vendorService));

Notes

• Populated only on the Dart BLE transport path. Host-native devices — including Bluetooth devices routed through host MIDI APIs such as CoreMIDI — report an empty list.
• UUIDs are normalized to lowercase 128-bit form via BleUuidParser. The pigeon-backed platforms already do this, but Linux and Web pass advertisement UUIDs through raw; normalizing keeps the field comparable everywhere. Unparseable entries are dropped.
• An advertisement without a service list does not clear previously seen UUIDs: advertisement and scan-response packets arrive separately and only one carries the list.
• Additive field with a const [] default, so the MidiDevice constructor and all subclasses stay source-compatible.

Tests

Four new cases in packages/flutter_midi_command_ble/test/ (exposure, normalization, empty-advertisement retention, replacement), plus an assertion in the platform-interface test pinning the empty-for-host-devices contract. flutter analyze clean; BLE, platform-interface and root suites pass.

Closes #134